Development Conventions

With the help of various conventions, we try to make it easier to find and discover the information needed, and understand the components’ internal consistency. The conventions used in products aimed at software development are built on top of Common Conventions.

Date and Time Conventions

• All OPC-related properties that are of DateTime type (and are consistently in UTC) have corresponding properties with a “Local” postfix, which contain the same value but expressed in local time. For example, DAVtq.Timestamp contains a timestamp in UTC, whereas its DAVtq.TimestampLocal contains the same in local time.

Naming Conventions

Common Naming Conventions

• In OPC-UA, the name part “MonitoredItem” is used wherever the type or member applies to both Data Access and Alarms and Conditions, whereas the names that use the term “DataChange” apply to Data Access only.

Type Names

In addition to being compliant with common Microsoft recommendations for names, and in the .NET part with Microsoft .NET Framework guidelines for names, we follow certain additional naming conventions:

• Types which are specific to very simplified (“easy”) model for working with OPC start with the prefix Easy.
• Types which are specific to OPC Data Access start with DA (or EasyDA) prefix, types which are specific to OPC Alarms and Events start with AE (or EasyAE) prefix. Types that are shared among multiple OPC specifications do not have these prefixes.
• Types which are specific to OPC Unified Architecture start with UA (or EasyUA) prefix. Types that are shared among multiple OPC specifications do not have these prefixes.

Note that the second and third conventions work in addition and together with the fact that there are separate DataAccess, AlarmsAndEvents, and UA namespaces for this purpose too.

The above described conventions also give you a bit of hint where to look for a specific type, if you know its name. For example, if the name starts with DA or EasyDA, the type is most likely in the OpcLabs.EasyOpc.DataAccess namespace. Without any special prefix, the type is likely to be in the OpcLabs.EasyOpc or OpcLabs.BaseLib namespace.

Interface Names in COM

As opposed to .NET, every object access in COM is solely made over its interfaces. In COM, after the object is instantiated, you never “see” the object as such – only the interfaces it has. Therefore, at least one additional interface (besides the COM-defined IUnknown and IDispatch) is needed on each .NET exposed to COM.

We consistently use following conventions in COM:

• Incoming interfaces have a form of _XXXX, where XXXX is the distinguishing part, e.g. _EasyUAClient, for the EasyUAClient object.
• Outgoing interface (for events) have a form of DXXXXEvents, where XXXX is the distinguishing part, e.g. DEasyUAClientEvents, for the EasyUAClient object.

The incoming interface are dual interfaces. The outgoing interfaces are dispatch-only interfaces, hence the use of ‘D’ as a prefix.

ProgIDs (COM)

In COM, all our objects have ProgIDs that are identical to their qualified type names in .NET. For example, the main EasyUAClient component resides in the OpcLabs.EasyOpc.UA namespace, and its fully qualified name and therefore also its ProgID is “OpcLabs.EasyOpc.UA.EasyOpcUA”. The main EasyDAClient component resides in the OpcLabs.EasyOpc.DataAccess namespace, and its fully qualified name and therefore also its ProgID is “OpcLabs.EasyOpc.DataAccess.EasyOpcDA”. This convention makes it easy to instantiate COM objects, based on the namespace-qualified names of their .NET counterparts.